[Previous] [Next] [Index] [Thread]

Re: SSLv3 MAC calculation

Jeroen de Borst wrote:
> 
> Hi,
> 
> I need some help, I found 2 differenct specifications for the MAC
> calculation in SSLv3:
> 
> http://home.netscape.com/newsref/ssl/3-SPEC.htm#RTFToC20
> 
> does not include any padding, but adds SSLCompressed.type and

This is an old version of the spec.  I don't know why it's still out
there, but I'll see that it gets removed.

> http://home.netscape.com/eng/ssl3/3-SPEC.htm#7-2-3-1
> 
> does include padding but leaves out SSLCompressed.type.

This is the final version of the spec.  The MAC calculations specified
are wrong, however.  The correct MAC is specified in the errata, which
I've attached.

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | tomw@netscape.com

A careful reader was confused about the wording in section 7.6.9 on
the Finished message. The change below have been added to this errata
since the last message in the middle of April, 1996.

These comments are relative to the 3/4/96 released version of the spec
that is available via

        http://home.netscape.com/eng/ssl3/index.htm

=====================================================

The MAC algorithm in section 7.2.3.1 should be

      hash(MAC_write_secret + pad_2 + hash(MAC_write_secret + pad_1 +
            seq_num + SSLCompressed.type + SSLCompressed.length +
            SSLCompressed.fragment));

The SSLCompressed.type field was dropped on the floor (as well as the
more specific indication of the input data). The type field is needed to
prevent a message from being aliased among the handshake, alert or
client data streams. Two bytes of the SSLCompressed.length field are
fed into the hash.

= = = = = = = = = = = = = = = = = = = =

Section 7.4.1 on closure alerts is unclear. This may help:

        Each side (client or server) sends a closure alert
        before actually closing its end of the connection.

        It is not necessary for the first side that sends a
        closure alert to wait for a responding closure alert
        from the second side before it closes the connection.

        The second side is obligated to attempt to do the send
        of the closure alert, but must handle any errors that
        arise from the send due to the connection being closed.

        The first side may wait for the closure alert from
        the second but is not obligated to do so.

        The first does have the option of only closing its
        outgoing half of the connection.

= = = = = = = = = = = = = = = = = = = =

The diagram of the handshake in section 7.5 is missing the
ServerHelloDone message. It should be the final message at the end of
the first block under "SERVER". The CertificateRequest and
ServerKeyExchange messages are misordered in the diagram.

= = = = = = = = = = = = = = = = = = = =

In the discussion of the Finished messages in section 7.6.9, in the
third paragraph, change "the finished messages" to "this finished
message." Each hash in each finished message includes all of the
handshake data from both sides up to but not including the message
being constructed.  The input to the hash of the second side to send a
finished message includes the contents of the first finished message.

=====================================================


Section 7.4.1 on closure alerts is unclear. This may help:

        Either party may initiate a close by sending a closure alert.
        Any data received after sending the closure alert is ignored.
        Once the alert is sent, the connection is closed.

        The party that receives a closure alert aborts any in-progress
        transfers and then closes the connection.

        NB: It is assumed that closing a connection reliably delivers
        the data before destroying the transport.

=====================================================

For forward compatibility reasons, it's legal for a client hello message
to have extra data after the compression methods.  This data should be
included in the handshake hashes, but otherwise ignored.

=====================================================

Section 7.2.3.1 is unclear about the length for pad_2.  It is the same
length as pad_1.

In sections 7.6.8 and 7.6.9 the pad1 and pad2 values are the same as the
pad_1 and pad_2 values used in computing the MAC.
References: